An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.

What's the guidance on submitting new builds for App Review that include support for iPhone Duo/iPhone resizability? Will they work when building with Xcode 27 + if available for 27.1 or do we have to wait for new Xcode release? Any guidance from Apple and timeframe on build submission if our updates are ready and undergoing testing in simulator? Thank you.

Hi everyone, I was slowly working on an app for many years, five to be precise. It was a long way, with a custom video engine, chat UI, and a lot of life stuff in between, and I finally submitted it to the App Store last month. The idea of the app is that you can create videos that show a chat conversation, with animated text bubbles, text, typewriter effects, and so on. See an example: It is not a unique concept. I found many apps on the App Store like TextingStory and ChatTales, and many general-purpose video editors like CapCut, Canva, or Mojo have video templates that allow you to create similar chat videos. So conceptually, nothing really worried me. But my first submission got a 1.1.6 rejection: Guideline 1.1.6 - Safety - Objectionable Content Issue Description The app includes trick or joke functionality which is intended to or may be used to deceive users. Specifically, the app allows users to create fake chat conversations. Please note that adding a disclaimer to the app description is not sufficient if the rest of the metadata and the app could be misleading. Next Steps Revise the app so that it may not be used to deceive users. As a follow-up, I explained the app’s positioning as a video tool, as I believed this was some misunderstanding. The app is clearly focused on storytelling and creating videos. The output video is also not really trying to imitate an actual messaging screen, as it doesn’t contain UI chrome such as a status bar, navigation bar, text input controls, timestamps, or delivery/read receipts. So I updated the app and metadata to present the storytelling and video export purpose more clearly. After about 10 days waiting for the second review, I got essentially the same rejection: The app still creates fake chats. I am now trying to clarify with App Review what exactly can be changed. My hope is that removing features like "New Project from screenshots" and visual themes resembling existing messaging apps could help. But the biggest worry is that the category itself banned and the app won't be accepted at all. So I wonder if anyone here has experience dealing with a 1.1.6 rejection like this. The relevant part of the guideline says: False information and features, including inaccurate device data or trick/joke functionality, such as fake location trackers. Stating that the app is “for entertainment purposes” won’t overcome this guideline. Apps that enable anonymous or prank phone calls or SMS/MMS messaging will be rejected. Is producing chat style videos effectively forbidden as a category? As I mentioned there are existing apps, but as I understand that doesn't guarantee anything. What could distinguish a “fake chat” from a "non fake fictional chat video"? Has anyone had a similar rejection, and if so, what did Apple actually ask you to change?

My first app (version 1.0, iOS) was submitted on 12 September 2026 at 01:01 UTC and has been sitting in "Waiting for Review" ever since. Eight days later it has still never moved to "In Review". There are no messages from App Review in App Store Connect: no rejection, no request for information, nothing. I have checked everything on my side and it all looks correct: Paid and Free Apps agreements: Active Banking and tax forms: Active EU DSA trader status: completed, shows as Active (this one had already blocked an earlier submission for four days without any email from Apple, so I know to look there) App Review Information complete, with notes explaining that the app ships with a built-in sample mailbox "Sign-in required" is unchecked, so no demo account is needed to review it Metadata, screenshots, age rating and export compliance all complete A valid build is attached I also deleted an empty submission draft that had been left behind by the App Store Connect API One thing I am unsure about: while preparing the release I cancelled and resubmitted the version several times to swap the build, and the submission history now shows a number of entries marked "Removed". Does cancelling a submission and resubmitting send the app back to the end of the review queue? I have opened a support case as well, but I would appreciate hearing from anyone who has seen a first submission sit this long, and whether it eventually cleared on its own.

I am trying to add testers to External Tester groups for a couple of our iOS apps and after adding them it shows "No Builds Available". This is despite the app being available to that External Tester group with other people having already installed the latest version of the app which is "Available" and not expired. Can someone please fix this? It is so frustrating the number of times I try and release apps to TestFlight and there's some issue blocking me, completely out of my control and I have to rely on someone at Apple fixing something on this terrible AppStoreConnect system.

Hello Team, it's been more than 10 days since i submitted by App after they ask for clarification. and it is still not reviewed. initially i submitted app on 28 Aug. can anyone please help me

Hello Apple Developer Community, I am an independent developer and I am looking for some guidance regarding the App Review process for my app, Zivoo. The review process has been ongoing for about four months, but I still have not been able to get a clear explanation of what Apple expects me to change. The main problem now is that App Review is no longer responding to our clarification messages in App Store Connect. We have already sent detailed questions, additional explanations, information about our previous Bundle IDs, and technical supporting materials, but we have not received a response. Zivoo has never been released on the App Store. During the review process, we submitted the app under the following Bundle IDs: confident.zivoo ru.zivoo.social ru.zivoo.talk All of them belong to the same Apple Developer Team. After previous rejections and major changes to the app, we deleted the earlier App Store records because we mistakenly believed that a substantially redesigned product should be submitted under a new App Store record and Bundle ID. Previously, Zivoo was rejected under Guideline 4.3(b). After that, we significantly redesigned the product. We removed profile browsing, swipes, likes, and mutual-like mechanics. The current version focuses on language practice through active conversation rooms and AI-assisted room discovery. The latest submission was rejected under Guideline 4.3(a). The rejection says that the app shares a similar binary, metadata, and/or concept with other submissions. We asked App Review to clarify what exactly this refers to: our own previous Zivoo submissions, shared third-party SDK components, or specific code, assets, metadata, or product concepts that Apple considers similar to another app. Unfortunately, we have not received a specific explanation, and currently we are not receiving any response at all in App Store Connect. We have already provided our full Bundle ID history and a technical report showing the size and contribution of third-party SDKs. I am also ready to provide the client and backend source code, Git history, original design files, dependency information, or a live technical demonstration if that would help clarify the situation. I would really appreciate any advice from developers who have dealt with a similar 4.3(a) or 4.3(b) situation, especially when previous Bundle IDs of the same app were involved. Apple App Review has completely stopped responding to us in App Store Connect. We have sent several clarification messages with detailed technical information and questions, but have not received any response. Thank you.

hii submitted app yesterday to review, This morning I was surprised that the application was rejected, Reason 4.3 Design: Spam.And I've introduced an application programmed by myself, and a unique design.This message I receivedGuideline 4.3 - DesignWe noticed that your app provides the same feature set as other apps submitted to the App Store; it simply varies in content or language, which is considered a form of spam.The next submission of this app may require a longer review time, and this app will not be eligible for an expedited review until this issue is resolved.what should I do ?

Hi, Our app update has been sitting in "Waiting for Review" for 7 days and has never transitioned to "In Review". App: NotBetting: Pronosticos Apple ID: 6737483983 Bundle ID: com.notbetting.mobile Version: 3.3.5 (build 193) Submitted: September 12, 2026, 15:49 UTC Current state: Waiting for Review (unchanged since submission) For context, our last released version on the App Store is 1.2.3, from June 24. Our users have been waiting a long time for this update, and the current delay is becoming a serious problem for us. Nothing was changed on our side after submitting, and the build is not a resubmission of a rejected binary. Is there anything we can check on our end, or any additional detail we can provide to help move this forward? I am happy to share a Case ID or anything else that helps. Thank you.

I submitted my first APP for review and it was rejected. Below is what they said. I have tested this APP on every simulator I can find, but I can't find an iPad Air Gen 5 with iOS 27. iOS 26.5 is the best I can find. But every device I test it on, it works just fine. I have asked for more clarification, because I don't know what to do now. Any advice or assistance would be appreciated. Bug description: We were unable to use any core feature, because no further action occurred when we were tapping any option/feature. Review device details: Device type: iPad Air (5th generation) OS version: iPadOS 27.0 Internet Connection: Active

Hello, I need some assistance with how to present the tools without apple keeps saying I´m breaking the rules. Issue Description " The app or metadata includes content that some users may find upsetting, offensive, or otherwise objectionable. Specifically, the app still allows body morphing. Next Steps To resolve this issue, remove all potentially objectionable content from the app and metadata and submit the revised binary for review. " The big deal is this template, which i still dont understand why i have problems and other apps dont, even when they used photos with bigger dimensions and more "provocative" They said i was doing body shaming, then that you could create people in intimate contact or kissing and so on, and obviously none of that was accurate. And i deleted all that for this version, well i hidde it, so users can not acces to it, but i guess like the message says, metadata. but about the body transformation i really dont understand why my app is wrong and other apps that i could totally name seems to have no problem at all with their templates. They already made me delete some features that were only liquify effects and now this. i already try to have phone calls, they even gave the number of guy which i called and he even said that he did not understood why they rejected the app since it was not doing body shaming nor creating what they said it could.

Hello, I am looking for guidance on a submission that has been in review for an unusually long time, and to ask whether other developers are seeing the same thing. App: Kids Coloring & Learning Games Apple ID: 6754971485 Platform: iOS Support case: 20000144299546 Timeline: 14 Aug 2026 — submitted, entered Waiting for Review 14–24 Aug — no movement (10 days), never entered In Review 25 Aug — cancelled and resubmitted the identical build ~3 Sept — entered In Review Today — still In Review That is 35 days since first submission and about 17 days in In Review. I have contacted Developer Support and my expedited review request was accepted and confirmed. Despite that, there has been no further movement and no communication. There are no messages in Resolution Center and the review team has not asked me for anything. This is an update to an app already live on the App Store, in the Kids Category with in-app subscriptions. The build itself is unchanged from a version that was previously approved. My questions: Is there a way to find out whether something specific is blocking this review, as opposed to it simply being queued? Are other developers currently seeing extended In Review times, particularly for Kids Category apps with subscriptions? Is there anything further I should do, or is waiting the only option at this point? I would rather fix a problem on my side than keep waiting if something is actually wrong. Any guidance would be appreciated. Thank you.

Hello Apple Developer Community, I am an independent developer and I have reached a point where I genuinely do not understand what the correct path forward is. I have invested a very significant amount of personal time and money into Zivoo. The app has never been released on the App Store. Every time App Review provided feedback, I tried to address it seriously and substantially redesign the product instead of simply resubmitting the same application. The first versions of Zivoo focused on real-time social communication. Later, the app was rejected under Guideline 4.3(b) because Apple considered the experience too similar to existing dating apps. In response, we substantially redesigned the product again. Profile browsing, swipes, likes, skips and mutual-like mechanics were removed. The current Zivoo is focused on language learning and real-time language practice through active conversation rooms, AI-assisted room discovery, entry requests, live conversations, voice/video messages, reactions, shared mini-games and invitations for future practice. The application-specific code, backend, UI system, custom assets, product logic and more than 35 custom animations were developed specifically for Zivoo. We have never purchased a white-label app, cloned another application, purchased an app template or repackaged another developer's product. We do use standard third-party SDKs such as Yandex Mobile Ads, mediation SDKs, Firebase, AppMetrica, Lottie and others. During this process, we may also have made an important mistake. Previous Zivoo submissions used: confident.zivoo, ru.zivoo.social The current submission uses: ru.zivoo.talk All of these Bundle IDs belong to the same Apple Developer Team. Zivoo has never been published on the App Store, and multiple versions of Zivoo have never been publicly distributed at the same time. After previous rejections and major redesigns, we removed previous App Store records. Because the concept had changed significantly, we mistakenly believed that the redesigned product should be submitted under a new App Store record and Bundle ID. This was never intended to bypass App Review or distribute multiple copies of the same app. The current submission has now been rejected under Guideline 4.3(a), stating that it shares a similar binary, metadata and/or concept with apps submitted by us or other developers. The most difficult part of this process is that we are never clearly told what exactly is considered wrong. With each rejection, we receive a broad guideline reference, but not a specific explanation of which code, asset, metadata element, feature or concept triggered the decision. We currently see two possible explanations: Apple's systems may be matching the current submission against our own previous Zivoo submissions under different Bundle IDs. Shared third-party SDK components may be contributing to the binary similarity signal. Our technical analysis shows that standard third-party libraries represent a substantial portion of the measured build. We fully understand that this does not prove that the SDKs caused the rejection. At this point, however, I am afraid to simply make random changes and resubmit again, especially because the latest rejection also includes an Extended Review warning. I am not asking for automatic approval or special treatment. I simply want to understand what Apple actually expects us to fix. Can 4.3(a) be triggered by a developer's own previous submissions under different Bundle IDs, even if none of them were ever released? Can common third-party SDKs contribute to the similarity determination? And if Apple believes our application-specific code, assets or concept are similar to another developer's app, how can we verify or address that? I am prepared to provide client and backend source code, Git history, original design files, dependency information, build details and a live demonstration. If anyone has experienced a similar case, especially after removing previous app records and submitting a substantially redesigned version under a new Bundle ID, I would greatly appreciate hearing how it was resolved. If Apple Staff sees this post, I would be extremely grateful for concrete guidance on what exactly we should do next. Thank you.

Hi everyone, I'm looking for advice from developers who have dealt with Guideline 4.3 in a situation involving a previously terminated Apple Developer account. We have a legitimate travel booking application that was previously submitted to the App Store under our original Apple Developer account. Unfortunately, that developer account was terminated, and despite multiple appeals/support requests, we were unable to have the account restored. We subsequently created a new Apple Developer account and attempted to submit the same legitimate travel application under the new account. The current application has a significantly redesigned UI and UX, but the mobile application is still based on the original React Native codebase. The backend, APIs, travel integrations, booking system, etc. are our existing platform and are not copied from another application. The submission is now being rejected under Guideline 4.3 with wording indicating that the app shares a similar binary, metadata, and/or concept with apps previously submitted by a terminated Apple Developer Program account. My question is specifically about understanding what Apple may be identifying in this situation. Has anyone experienced a similar case where: The same legitimate product was previously submitted under a terminated developer account. The developer then had to submit it from a new account. The new submission was rejected under 4.3 because of its relationship to the previous app/account. If so, were you able to determine whether Apple's concern was primarily: the binary/source-code similarity, the previous developer account association, metadata/assets, or the fact that it was essentially the same product? I'm considering rebuilding the iOS client from React Native to Flutter as a genuinely new implementation while keeping our existing backend/API platform. Before investing significant development time in that rewrite, I'd like to understand whether changing the mobile technology would actually address this type of 4.3 issue, or whether the previous account association can still cause the rejection regardless of the framework. I'd also appreciate any experience with getting a specific answer from App Review about what triggered the 4.3 rejection in cases involving a terminated account. Thanks in advance.

Hi everyone, I would like to ask if anyone else has experienced a longer-than-usual "In Review" phase recently. Here is the timeline for our app, App ID: 6800282515: Submitted for Review: Sep 14 at 05:00 Pacific Time Checked and found status in "In Review": Sep 14 at 19:00 Current Status: Still "In Review" (as of Sep 17, 19:00+) It has been in the "In Review" state for over 3 full days without any updates, rejection notices, or requests for additional info. Has anyone run into a similar issue lately? Is there any recommended way to handle this, or should we just wait a bit longer? Any advice would be greatly appreciated!

A week ago I sent an app for review with 2 platforms (iOS + tvOS). It had a couple IAPs and I attached them to the iOS submission. Then I sent tvOS for review. For my surprise, platforms are reviewed individually and with different timings. Perhaps tvOS / macOS has less released apps than iOS and their queues are smaller. What happened, you guessed it, tvOS got approved and iOS was still queued. Consequence: people on tvOS couldn't buy any of the IAP because they were attached to the iOS submission. Lesson learned: when having more than one platform in review, make sure you change app launch from automatic to manual so you can wait for both being approved and then release them whenever you want.

Hello, Our app (Apple ID 6797897487) is an internal operations tool built under contract for a single business. It was rejected under guideline 4.3(a) on 29 August. We replied in App Store Connect on 31 August and on 10 September, adding that Apple had approved unlisted app distribution for the app on 8 September, but we have not received any response since. What is the recommended next step here? Should we resubmit the same build with the updated information, or wait for a reply to the existing messages? Thank you.

Our app, Roll (Apple ID: 6797953438), has received two Guideline 4.3(a) spam rejections. Our responses have gone unanswered for almost 3 weeks, and then we got an account warning. August 27: First rejection. We replied requesting clarification, explaining the app’s functionality, and supplied a walkthrough video. September 14: After almost three weeks without clarification, we submitted a substantially revised build with new functionality. We included an explanation directly in the App Review notes. September 15: The exact same rejection, still without identifying the issue or addressing our notes to them. This time, it included a warning about account removal for repeated noncompliance. It seems Apple is refusing to read our replies. Instead, they got back to us with the same rejection and a warning. For what? Doing as we were told and writing a reply? Note that thus far, NONE of our replies have even been acknowledged. Has anyone resolved a similar 4.3(a) rejection? What helped you get specific clarification or a call with App Review?

Hello App Review, Our iOS app was rejected under Guideline 5.6 (Developer Code of Conduct). The message states that the app appears to contain features intentionally hidden during review, and that this pattern is commonly associated with fraudulent activity. We want to address this correctly, but the current note does not identify the specific flow, screen, or behavior that was observed. Without that, we cannot investigate the exact issue. Could a member of App Review please follow up in App Store Connect with more concrete detail, or advise what we should check? @WWDR App name: Prime Cedi Loan Apple ID: 6808185084 Version: 1.1.0, Build 2 Guideline: 5.6 We have already replied in Resolution Center and are ready to provide test accounts, a demo video, or a phone call if that would help. Thank you.

Hi, our prediction market app, Even, has been rejected under Guideline 5.3.4. Even is a mobile frontend built on Polymarket’s markets and trading infrastructure. Apple says we have not provided licensing and permission documentation for every country or region selected in App Store Connect. It has also asked us to limit App Store availability and app access to licensed locations. We’ve added geoblocking so users in restricted regions cannot place orders; they can only browse public market information in read-only mode. We also updated our App Store description to explain our relationship with Polymarket and the regional restrictions. We’ve noticed other prediction market apps that appear to be available across many App Store regions with trading enabled. We may not know what licenses or arrangements those developers have, but we’d appreciate help understanding why our submission is being treated differently and what evidence Apple needs from us. For a third-party frontend, does Apple require our own licensing documentation for each region, or could authorization and documentation from the underlying market operator satisfy review? Is read-only access in restricted regions insufficient under Guideline 5.3.4?

Hey Apple Developers! I am about to release my first iOS Application, but I am having a hard time with the app reviews. Here some curiosities I just don't understand. Hopefully you can tell me why the app was rejected and what I have to do in order to make it work... Review A: Apple first responded with: Guideline 2.5.4 - Performance - Software Requirements Due to the usage of Bluetooth Low Energy and the Core Bluetooth framework and Guideline 2.1 - Information Needed The App Tracking Transparency permission request, due to the usage of Ad frameworks. So I created a video in which I explained why I need it and anotherone where the ATT dialog appears. (since I am from germany, I even used a VPN to "simulate" the appearance of the ATT Dialog in the US, since in the EU dialog this looks a bit different. The EU version of it was visible in the initial video I provided. After that (still same request ID) it got rejected because the IAP was missing in the review request, even though it was in there. BLE and ATT wasn't a problem anymore I thought, well may be they've overseen the IAP, so I created a complete new request, uploaded a new (further developed) application. No changes on the IAP, ATT nor BLE parts. Review B: Again this was declined, for the same reasons review A was declined the first time. I explained EXACTLY the same thing, as in review A. The only answer was: We appreciate your efforts to comply with the App Review Guidelines. Please resubmit the app for review in App Store Connect once any necessary adjustments have been made. We look forward to reviewing your resubmitted app. I thought: Well, may be it's not possible to approve an app that was once declined (as mentioned this is my first review) So I created a new review request. Review C: Including a new video for the app itself (I was had developed some progress already) and the BLE video again (to prove the usage of CBPeripheralManager and CBCentralManager) It got decline AGAIN. Reasons: Guideline 2.5.4 - Performance - Software Requirements BLE again Guideline 5.1.2(i) - Legal - Privacy - Data Use and Sharing ATT Problem again. Again, explained where to find it and even provided timestamps for the videos on where to find the ATT. (There were 2 reviews upfront this story without the Ad/ATT part already, that's why I wrote "...5th request") I am very frustrated right now and I have no clue what I am supposed to do here. It might be that I am doing something wrong here (as mentioned, first apple review), but please, let me know what that is!